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Abstract 

This paper describes a communication test, which 
successfully demonstrated the transfer of loss- 
lessly compressed images in an end-to-end sys- 
tem. These compressed images were first 
formatted into variable length Consultative Com- 
mittee for Space Data Systems (CCSDS) packets 
in the Advanced Orbiting System Testbed 
(AOST). The CCSDS data Structures were trans- 
ferred from the AOST to the Radio Frequency 
Simulations Operations Center (RFSOC), via a 
fiber optic link, where data was then transmitted 
through the Tracking and Data Relay Satellite Sys- 
tem (TDRSS). The received data acquired at the 
White Sands Complex (WSC) was transferred 
back to the AOST where the data was captured 
and decompressed back to the original images. 
This paper describes the compression algorithm, 
the AOST configuration, key flight components, 
data formats, and the communication link charac- 
teristics and test results. 

1.0 INTRODUCTION 

With the advent of sophisticated scientific satel- 
lites, space data communication systems are 
becoming more complicated in order to handle 
advanced instruments which generate variable 
data rates and formats. The desire to provide inter- 
national cross-support across different platforms 
in order to better utilize the science data globally 
has prompted the international CCSDS to issue a 


recommended standard on space data system archi- 
tecture specified in the Advanced Orbiting System 
(AOS) Blue Book [1]. This architecture provides 
flexibility to transport space data between plat- 
forms, ground stations and commercial data net- 
works. To demonstrate the capability of this 
architecture, Goddard Space Flight Center (GSFC) 
has been developing a testbed for the AOS. The 
key components of the AOST is implemented in 
hardware in order to provide insight regarding 
achievable speed and limitations for actual flight 
hardware. The block diagram in Figure 1 shows 
these key components including an instrument sim- 
ulator followed by a packet generator, a high-speed 
multiplexer, additional instrument simulators, and a 
virtual channel transfer frame generator. 

The testbed is capable of implementing the packet 
data architecture specified in the standards book 
and re-illustrated in Figure 2. A salient feature of 
the data architecture is the ability to transport vari- 
able-length CCSDS packet, as opposed to the con- 
ventional fixed-length packet structures. This 
structure allows packet data from different instru- 
ments to be multiplexed in a much more flexible 
way in the data system. For data originating from 
one single instrument, the variable-length packet is 
also a natural structure for holding the variable- 
length bit string resulting from losslessly compress- 
ing fixed-length instrument data, such as from a 
scan line of image data. 
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In parallel with AOST effort, GSFC is also 
engaged in the development of data compression 
technology. Data compression provides a viable 
means to alleviate the demands on onboard stor- 
age, communications bandwidth, station contact 
time and ground archive requirements. There are 
two types of data compression: a lossless tech- 
nique, which guarantees full reconstruction of the 
data; and a lossy technique, which generally gives 
higher data compaction ratio but incurs distortion 
in the reconstructed data. Lossless compression 
generally results in variable length compressed 
data due to statistical nature of the original data. 
To satisfy the many science disciplines, lossless 
data compression has become the priority for 
development. After extensive research, the Rice 
algorithm [2,3] was chosen and developed into 
hardware. In 1991, a hardware engineering model 
was built in an application specific integrated cir- 
cuit (ASIC) for proof of concept. This particular 
chip set was named the Universal Source Encoder/ 
Universal Source Decoder (USE/USD) (Venbrux, 
92) [4]. Later, it was redesigned with several addi- 
tional capabilities and implemented in Very Large 
Scale Integration (VLSI) circuits using gate arrays 
suitable for space missions. The flight circuit is 
referred to as Universal Source Encoder for Space 
(USES). The fabricated USES chip is capable of 
processing data up to 20 Msamples/second and 
will take data of quantization from 4-bit to 15-bit 
[5]. In the following sections, we will provide a 
brief description of the data compression algo- 
rithm, the overall communication system, the 
AOST and physical link characteristics. 

2.0 THE LOSSLESS DATA 

COMPRESSION ALGORITHM 

The architecture of the Rice algorithm is shown in 
Fig. 3. It consists of a preprocessor to decorrelate 
data samples and subsequently map them into 
symbols suitable for the entropy coding module. 
This entity is a collection of options operating in 
parallel over a large entropy range. The option 
yielding the least number of coding bits will be 
selected. This selection is performed over a block 


of J, typically 16, samples to achieve adaptability 
to scene statistics. An identification field of a 
fixed number of bits, determined by the input 
sample quantization levels, is used to signal the 
selected option for the block. The performance of 
this algorithm has been shown to be the same as 
that of a collection of Huffman codes on typical 
imagery [6] and has been tested on various instru- 
ment data [7]. 

3.0 SYSTEM DESCRIPTION 

3.1 End to End System Description 

The end-to-end system is depicted in Figure 4. 
The AOST is linked via an optical fiber to the RF 
SOC, which transmits the packetized data to the 
White Sands Complex (WSC) via a TDRS on a 
Ku band carrier. Data was recorded at the WSC 
and later transmitted to the AOST via NASA 
communication (NAS COM). 

3.2 Source Equipment 

3.2.1 Data Source 

The source data can be either simulated instru- 
ment data or a video frame of data acquired from 
a CCD camera. In both cases, the data is first 
loaded into a frame buffer before each scan line is 
passed to the compression hardware which incor- 
porates the USE chip. Each compressed scan line 
is then passed to the packetizer for further pro- 
cessing. 

3.2.2 Packetizer and Multiplexer System 
Description 

The packetizer takes data from the instrument, 
encapsulates it into CCSDS packets [8], and sends 
them over a fiber optic transmitter- receiver inter- 
face (FOXI) at a burst transfer rate of 80 Mbps. A 
separate packet is formed for each video scan line 
with the segmentation flag in the packet header 
used to treat an entire video frame as a large data 
block. The segment flag is set to “beginning of 
segment” for the first scan line of a video frame; it 
is set to “continuation segment” for intermediate 
scan lines; and it is set to “end of segment” for the 
final video scan line of a video frame. Frame syn- 
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chronization is derived through control signals in 
the FOXI interface. 

The multiplexer operates in two modes: 1) path 
service mode where the multiplexer passes 
CCSDS packets through to the Wideband Transfer 
Frame Formatter (WTFF) without processing and 
2) virtual channel access (VCA) service mode 
where the multiplexer produces multiplexing pro- 
tocol data units (MPDU) and transmits them to the 
WTFF. Access to the output channel is granted 
based on availability and a round robin polling 
sequence. This polling occurs once every 400 ns, 
which is rapid enough that it results in a statistical 
multiplexing function. In general, the higher the 
packet rate for a channel, the more the number of 
requests and grants are given to that channel, caus- 
ing access to be data rate driven. Details of the 
hardware are provided in [9]. 

3.2.3 Wideband Transfer Frame Formatter 
(WTFF) 

The WTFF system [10] is designed to serve as a 
gateway providing transfer frame generation using 
a subset of the AOS services, as defined in Refer- 
ence 1, for up to seven user virtual channels (VC) 
plus an idle channel. Data messages arriving from 
any one of the user VCs are buffered and then 
inserted into CCSDS standard format data transfer 
frames. These frames are padded with frames from 
the idle channel as necessary to maintain a preset 
data rate and are output on a single serial line. 
CCSDS Grade-2 service is provided by including 
a Reed-Solomon (RS) (255,223) error correcting 
code in each of the eight virtual channel circuits to 
form coded virtual channel data units (CVCDUs 
formed from VCDUs or MPDUs, Fig. 2). 

Virtual Channel: A VC unit receives user data 
and formats it into virtual channel frames (i.e., 
CVCDUs) at rates up to 100 Mbps. The frames are 
composed of five interleaved RS code words con- 
taining 255 bytes each. Each CVCDU is thus 1275 
bytes (10,200 bits) long, including the RS encod- 
ing check symbols. When CVCDUs are appended 
with a frame synchronization pattern (32 bits), a 
channel access data unit (CADU) is created, which 


can be transmitted over I or Q output data streams. 
Each VC is configured by the system controller 
upon initialization or during system re-configura- 
tion and has a unique ID (V CID) set by hardware. 
Data can be received as a fixed length data unit 
(MPDU in VCA service) or as CCSDS packets 
(Path Service). 

PN Code Transition Generator: To ensure bit 
transition, the pseudo-noise (PN) transition gener- 
ator is utilized. When it is, each byte of the 
CVCDU is XORed with a stored PN pattern 
before being sent through the multiplexer to the I 
or Q data outputs. The frame synchronization pat- 
tern is generated separately and is neither RS 
coded or changed by the PN generator. 

3.3 Data Capture Equipment 

All packetized data received at the WSC on the I 
channel was transferred to a workstation and pro- 
cessed predominantly with software tools. The Q 
channel signal was sent to a communications bit 
error rate (BER) test set for real time monitoring. 
The capture and analysis equipment is composed 
of a 32 Mbyte solid state memory connected to a 
Sun workstation via an ethernet; frame detection 
software; a hardware RS decoder; a software RS 
encoder; virtual channel and packet detection soft- 
ware; a software data decompressor; and a soft- 
ware image display package for the workstation. 

3.3.1 Frame Detector 

The original data as organized into frames by the 
WTFF is a series of bytes forming a data frame 
structure. Once transmitted from the WTFF, the 
bits in each byte are serialized and knowledge of 
the byte boundary is lost. The frame detection 
software searches the received file on a bit by bit 
basis to find the frame synchronization marker. To 
ensure that it is the frame marker and not a 
sequence of data bits that happened to be the same 
as the frame marker, the file position pointer was 
moved one frame length from the initial marker 
and data was examined for a second marker. In all 
of the data collected, a bit slip (or bit addition) was 
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never observed, making the need for a more elabo- 
rate frame synchronization strategy unnecessary. 

3.3.2 Reed Solomon Decoding 

After byte alignment and frame detection, RS 
decoding was performed. Each frame output from 
the RS decoder has a 16-byte status block 
appended to it. During the data flow with the com- 
pressed variable length image packets, the error 
rates were never severe enough to cause uncorrect- 
able frames. During the portion of the test where 
the purpose was to evaluate the Ku band physical 
link using the CCSDS structure, frames that were 
found to be uncorrectable were not deleted. They 
were examined for burst error statistics along with 
the correctable frames. When uncorrectable 
frames occurred, the data portion of the frame was 
corrected by computer using knowledge of the 
data structure, and the parity portion was gener- 
ated by re-encoding the data. CCSDS idle frames 
were also retained and RS decoded. The received 
raw data was compared with RS corrected data to 
determine burst error statistics. 

3.3.3 Channel and Packet Detection 

The file created after RS decoding was then pro- 
cessed by a software program called CHANNEL 
which examined the CCSDS frame header and 
produced a separate output file for each virtual 
channel identification (VCID) number that was 
found. Compressed video packets were assigned a 
particular application identification (APID) on a 
particular virtual channel. The PACKET program 
was run on the V CID file of interest and produced 
separate output files for each APID found in that 
VC. The APID file of interest contained variable 
length packets of compressed video data. 

3.3.4 Decompressor 

The packet file associated with the image frame 
data was further broken down into a separate file 
containing one compressed image frame. These 
512 variable-length lines were decoded to generate 
one fixed-length image frame. In software, this 


decoding routine performed the decompression 
algorithm and simulated the operation performed 
by the Universal Source Decoder (USD) chip, 
realizing the lossless data decompression algo- 
rithm. The routine used the reference sample at the 
start of each compressed 512 sample line as well 
as the header information at the start of each com- 
pressed 16 sample block to convert the data back 
to its uncompressed format. The resulting 
512x512x8 bit binary image file was then accessed 
by a commercial display software package. 

4.0 TEST PARAMETERS AND LINK 
ANALYSIS 


4.1 Test Parameters 

Testing of the AOST using variable length packet 
structures was performed by using losslessly com- 
pressed images. The first image transmitted was a 
prestored Landsat image. After the Landsat image 
was received, real time images from the video 
camera and packetized data from the simulators 
were routed through the source equipment and 
output on the WTFF I channel at 80 Mbps while 
the WTFF Q channel was not used. PN data trans- 
mitted on the RF Q channel was used to monitor 
the link BER. The WTFF I channel was config- 
ured to run at a continuous output rate of 80 Mbps 
(including idle channel fill frames) by using an 80 
MHz crystal on its high speed output board. The 
WTFF configuration was as follows: 

Virtual Chan- Virtual Chan- Data Source Data Rate " 

nel # nel Mode 

1 Path Service Simulator 16.0 Mbps 

2 VC A Service CCD camera ~28 Mbps 

3 Path Service Simulator 16.0 Mbps 

63 Idle channel WTFF as needed 

4.2 Link ANALYSIS 

In addition to evaluating compressed variable 
length packets, this test allowed an examination of 
the channel characteristics of the K-band Single 
Access (KSA) return link through TDRSS. The 
primary objective was to evaluate a BCH code 
proposed for a LANDS AT- 7 300 Mbps return link. 
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It was important to understand the error character- 
istics of the channel because the proposed binary 
BCH code (1023,993,3) can only correct 3 bit 
errors in a block of 1023 bits. This section will 
concentrate on the performance of the link used in 
this experiment in terms of BER vs. Eb/No. Link 
analysis was performed by transmitting a PN data 
pattern of NRZ-M data at 300 Mbps, QPSK modu- 
lated (150 Mbps on 1, 150 Mbps on Q) through the 
KS A return channel. The data was recorded in one 
minute samples, and six pairs of C/No and BER 
measurements were taken at WSC with 2 23 -l and 
2 -1 PN coded data. The measurements are sum- 
marized in Table 1. Using the measured carrier to 
noise density, the required effective isotropic radi- 
ated power (EIRP) values were also calculated. 

TABLE 1 . C/No, BER and RF SOC EIRP Data Points 


Measured C/No 
(dB) 

Measured Bit 
Error Rate 

EIRP Required for 
Measured C/No 

95.1 

0.8e-3 

51.2 

95.3 

3.5e-4 

51.4 

96.5 

9.0e-5 

52.6 

98.9 

2.0e-5 

55.0 

99.3 

3.0e-6 

55.4 

99.9 

2.0e-7 

56.0 


A plot of the six data points are shown in Figure 5 
along with the ideal BER vs. Eb/No curve. The 
separation from the ideal curve varied with each 
measurement, about an average of 3.6 dB foi five 
of the data points. This value was taken as the 
implementation loss. It is important to note that for 
the required EIRP calculation, several loss param- 
eters were assumed based on estimates and the 
weather conditions of that day (which was cloudy 
with light rain) at the transmit site. 

5.0 RESULTS 

Since the WTFF used the CCSDS recommended 
(255,223) RS code, it was expected thru as long as 
the BER was about l^lO -4 or better, the RS decod- 
ing would correct all of the errors. It was therefore 
expected that the decompression process would be 
error free and the reproduced image would be 


identical to the digital version of the original. This 
was found to be true. 

5.1 Image Quality 

No streaks or drop outs occurred in the images. 
Since the compression technique was applied 
independently to each scan line, a decompression 
error would be expected to corrupt an entire line. 
Loss of a user data CCSDS frame would impact 
several image lines, but no corruptions were 
observed. 

5.2 Channel Performance 

One of the concerns was to evaluate the burst 
errors on the TDRS Ku band link. A test cannot 
examine all the parameters that vary over a satel- 
lite’s lifetime, but it can at least provide a snapshot 
of some of those parameters. In order to simulate 
an end-to-end system, the data was recorded at the 
WSC and retransmitted to GSFC before being 
finally decoded. 

During the link portion of the test, differential cod- 
ing (NRZ-M) was used to avoid data inversion. 
The disadvantage of NRZ-M is that it causes each 
error to appear as two errors which may or may 
not be consecutive. In the data observed, no errors 
greater than 2 bits in length (errors were always 
consecutive) were observed when the proposed 
Landsat 7 power level was used. At lower power 
settings, where the BER was greater, longer burst 
lengths were seen (Table 2). For this analysis, a 
burst was arbitrarily defined as a group of incor- 
rect and correct bits where there were no more 
than 11 consecutive correct bits. A burst always 
starts and ends with an error. 


TABLE 2. BER vs. Error Burst Characteristics 


BER 

Max Length of 
Burst 

Max Errors Per 
Burst 

2.2e-5 

2 

2 

1.3e-4 

14 

4 

8.5e-4 

22 

6 


The CCSDS frame sequence count was continuous 
with no gaps. Bit slips (or additions) were never 
observed in this or other AOST tests with the 
TDRSS. 
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6.0 CONCLUSION 


The CCSDS recommendations for AOS data 
architecture have been put to a physical test with 
compressed data being multiplexed with several 
separate instrument channels. Losslessly data 
compressed images were received and decom- 
pressed without any distortion. The achieved 
compression ratio is about 1.8 for the Landsat 
image. This type of compressed data is very sen- 
sitive to channel errors which, if they occur, 
cause long streaks in the recovered images as 
results of the decompression operation. Therefore 
one can say that the data generation and recovery 
system worked as expected. No problems were 
introduced by the variable length packets result- 
ing from lossless compression. The Ku band 
TDRSS link contained errors consistent with a 
purely thermal (random) environment for data 
transmitted from the GSFC. This analysis is 
based on statistics gathered during a short period, 
therefore no statement can be made about the 
burst environment that would be observed when 
the TDRSS antenna is pointed toward other areas 
of the Earth. 
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Figure 1. AOS Test Bed Key Components 
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Figure 3. Rice Compression Algorithm 
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Figure 4. End to End Test Block Diagram 
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Figure 5. End-to-End Test BER vs. Eb/No 





